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10 La pr6sente invention a pour objet nn procede pour la determination de 
caract^ristiques operationnelles d'un programme. 

Eile s' applique notamment a la validation d' applications par rapport a des 

criteres operationnels specifiques donnes et, en particulier, a rautomatisation 'X 
15 du coiitrole du programme en vue de son execution sur des plates- formes 
cibies par des utilisateurs donnes. 

L' invention concerne 6galement un systeme mettant en oeuvre le procede selon f 
^invention pour garantir que des applications proposees par un serveur 
20 respectent des criteres de validite associes aux plates- formes d' execution de 
ces applications. 

La piupart des petits systemes embarques (terminaux de paieraent, organiseurs 
electroniques, telephones mobiles, cartes k puce, etc.), realises il y a quelques 

25 annees, etaient des systemes fermes ne pouvant executer que des programmes 
determines installes lors de la fabrication. De meme, bien que 
fonctionnellement plus ouverts, la piupart des ordinateurs etaient d^connectes 
de tout reseau et les quelques programmes qu'ils executaient avaient pour 
origine des editeurs de logiciels bien identifies. Du fait de cette faible 

30 variabilite, il etait alors possible de « contenir » les defauts de fonctionnenient 
des plates-formes d' execution et des programmes. 
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Aujourd'hui, la tendance est a I'ouverture des petits systemes embarques : 
m6me si la maitrise n'en revient pas toujours directement a Tutilisateiir final, 
on peut desonnais charger de nouveaux programmes sur ces plates-formes 
5 d' execution. Par ailleurs, beaucoup d'ordinateurs et de systemes embarques 
sent comiectes, temporairement ou non, a des reseaux (Internet, telephonic 
mobile, etc.) sur lesquels sont telecharges des programmes aux origines 
souvent inconnues et aux fonctionnalites souvent indeterminees. Enfm, la 
segmentation des marches et la multiplication des foumisseurs, des modeles 
10 materiels et des versions logicielles conduisent, malgre la definition de 
standards, a des combinaisons de configurations qui n'ont pas toujours ete 
anticipees, Cette situation accentue les risques de dysfonctionnement, 
notamment en ce qui conceme la securite et Tinteroperabilite. 

15 Volontaires ou involontaires, les dysfonctionnements d'une application 
concement en premier chef la securite. Une application peut par exemple 
effectuer des operations illicites (divulguer un code secret, se connecter a des 
sites non autorises, effectuer .silencieusement des envois de messages, etc), 
effectuer des operations licites mais pour lesquelles elle n'a pas les droits 

20 appropries, consommer plus de ressources que ce a quoi elle peut pretendre et 
ainsi en priver d'autres applications, alterer des donnees precieuses, etc. 

Un autre souci majeur conceme Tinteroperabilite. En effet, une application 
peut faire appel a des fonctionnalites mat6rielles ou logicielles qui s'averent ne 
25 pas Stre presentes sur la plate-forme d' execution (par exemple parce qu'elles 
sont optionnelles ou limitees) ou qui sont presentes d'une maniere inattendue 
(par exemple a cause d'une incompatibiiite de version). Dans ce cas, 
Tapplication ne fonctionne pas ou fonctionne mal, ce que Tutilisateur final 
peut imputer ^ tort au fournisseur du service ou du materiel. 

30 
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Les consequences de ces dysfonctionnements peuvent Stre tres graves dans le 
cas de systemes critiques ot la securite est primordiale. C'est le cas par 
exemple pour les applications dans le domaine de la banque, de la sante, du 
transport, de I'identite, etc. Meme lorsque les dysfonctionnements sont 

5 mineurs pour les utilisateurs et ne se soldent que par de faibles degtts ou des 
indisponibilit^s des systdmes, les retombees commerciales peuvent eti-e 
d6sastreuses pour les fouraisseurs de materiel ou de logiciels : non seulement 
cela peut necessiter de couteux rappels de materiel, mais surtout cela pent 
endommager leur image aupres des consommateurs. Le risque est notamment 

0 manifeste pour les op6rateurs teI6phoniques qui permettent a leurs utilisateurs 
de tel6charger de nouveaux programmes dans leurs telephones mobiles. 

Outre les problemes de securite et d'interoperabilite, certains fournisseurs 
veulent aussi appliquer une discipline de deontologie (par exemple, pour le 
5 contrdle d'acces des mineurs), des principes d'ergonomie ou des regies de 
style (par exemple, pour le respect d'un « Look and Feel »). 

Le probldme qui se pose est en fait plus g6n6ralement celui du contrdle de 
I'adequation d'un programme a une ceitaine « politique » de security, 
> d'interoperabilite, etc. 



Avaat de repondre a la question du contr61e des programmes, une premiere 
etape consiste tout d'abord a etablir des criteres qui d6finissent s'il est 
acceptable ou non qu'un programme donne soit execute sur une plate-forme 
cible donnee (ou un ensemble de plates-formes) par certains groupes 
d'utilisateurs donnes. Des criteres de securite peuvent notamment atre issus 
d'une analyse de risque prdalable, qui evalue notamment les biens k proteger 
sur la plate-forme et dans les programmes, les menaces a I'encontre de ces 
biens, et les mesures k prendre pour s'en premunir. Des criteres 
d'interoperabilit6 peuvent 6tre tires des cas d'erreui- signales par les 6quipes de 
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test et les utilisateurs, ainsi que de T experience de bonne programmation des 
developpeurs. 

Par exemple, dans le cas d' application pour cartes a puce, un critere securitaire 
5 peut stipuler qu'il est interdit d'utiliser des cles « DES » trop faibles^ par 
exemple d'une longueur inferieure a 128 bits. De meme, un critere 
d'interoperabilite peut stipuler de ne pas utiliser de cle « RSA », ou de cles 
« RSA » de longueur superieure a 1024 bits, parce que la plate-forme cible ne 
permet pas de manipuler ce type de cles, ou des cles d'une telle taille, 

10 

Pour pouvoir eti-e verifies de maniere non ambigug, les criteres doivent 6tre 
clairement formules, Un critfere s'exprime souvent sous fonne de contraintes 
concemant Tusage de routines ou classes de librairies, Dans le cas 
d' applications « Java Card » (langage qui est specialise pour T execution sur 

15 une carte a puce), Texemple de critere securitaire ci-dessus s'exprime de 
maniere plus explicite par : « La methode « buildKey(keyType, keyLength, 
...)» n'est pas appelee avec un argument «keyLength» inferieur a 128 si 
r argument « key Type » est egal a la valeur de la constante « TYPE_DES » », 
(« Java » et « Java Card » sont des marques deposees de Sun Microsystems. 

20 Pour des raisons de lisibilite, le prefixe de classe 
« javacard.framework.KeyBuiider » sera volontairement omis). 

Ainsi le programme suivant satisfait-il le critere securitaire : 
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"void install(byten buf, short ofs, short leu) { 

switch(buf[ofs++]) { 

case 1 : // Use DBS 128 bits 

5 myKey = buildKey(TYPE_DES, LENGTH_DES3_2KEY)• 

break; ' 

case 2: // Use DBS 192 bits 

myKey = buildKey(TyPE_DES, LENGTH_DES3 3KEY)- 
break; ~ 
10 case 3 : // Use RSA 1 024 bits 

myKey = buildKey(TYPE_RSA_PRIVATE, LENGTH RSA 1024V 
break; - — j> 



20 



} 



15 } 



En effet, quels que soient les chemins d'execution, la methode « buildKey » 
est toujours appel6e avec des arguments compatibles avec le critere : ou bien 
«keyType» vaut « TYPE_DES » et «keyLength» vaut 
« LENGTH_DES3_2KEY » (^gal k 128) ou « LENGTH_DES3_3KEY » 
(egal a 196), ou bien « keyType » vaut « TYPE_RSA_PRIVATE » (difKrent 
de « TYPE_DES »). 



En revanche, le programme suivant ne satisfait pas le critere. 
25 void install(byte[] buf, short ofs, short len) { 

myKey = buildKey(buf[ofs++], buf[ofs-H-]); 



30 



35 



En effet, la valeur « buf » est un argmnent dynamique : il est done possible de 
construire des cles de type et de longueur arbitraire. En particulier, il est done 
possible que « buf[ofs] » soit egal d « TYPE_DES » et que « bufTofs+l] » soft 
inferieur a 128. 

En ce qui conceme le controle effectif d'un programme, I'etat de J'ait peut se 
resumer comme suit ; 
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Pour determiner si un programme domie satisfait des criteres doimes pour une 
plate-foniie dotmee, plusieurs approches sent aujourd'hui employees. Elles se 
distinguent selon plusieurs aspects : le controle est statique (avant T execution 
sur la plate-forme) ou dynamique (pendant T execution) ; le controle est « boite 
5 noire » (sans regarder le code) ou « boite blanche » (en regardant le code) ; le 
contr61e est « manuel » (sans Taide d'outils d'analyse) ou automatique (avec 
Taide d'un outil d'analyse). Les contrdles couramment employes sont les 
suivants : 

10 « Les criteres, notamment securitaires, peuvent etre mis en oeuvre par des 
controles dynamiques effectues au cours de Pex^cution du programme. 
Cette approche a trois desavantages majeurs. Tout d'abord, elle decouvre 
les problemes trop tard, une fois le programme deja charge et en cours 
d'execution. Ensuite, parce qu'elle n'a qu'une yision « boite noire » de 

15 Tapplication, elle necessite de bomer arbitrairement T exploitation des 
fonctionnalites et ressources de la plate-forme (par exemple, pas d' envoi 
de plus de trois messages). Enfin, elle ne resout pas les problemes 
d' interoperabilite. 

20 • Le programme peut aussi etre teste en boite noire, sans regai^der le code, 
Avec cette approche, le programme est execute dans un certain nombre de 
circonstances suppos6es representatives, et son comportement est observe 
de rext6rieur pour juger s'il respecte les criteres. Cette solution peut 
permettre de repondre a certaines questions iiees a Tergonomie, mais ne 

25 procure pas de garantie forte sur les questions de securite ou 
d'interoperabilite. En effet, on n' examine avec cette methode qu'un petit 
nombre de chemins d'execution possibles, alors qu'il en existe une infinite. 
Par exemple, des chevaux de Troie (programme ou donnees qui semblent 
inoffensives lorsqu'elles sont chargees sur la plate-forme mais qui facilitent 

30 ensuite une attaque, par exemple par un pirate ou un virus) ne peuvent etre 

detectes a coup s0r. 
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• Le programme peut 6tre conti-ole manuellement, en regardant le code mais 
sans I'aide d'un outil d'analyse. Cette solution a de nombreux 
desavantages. Un tel controle est en effet long (done couteux) et fastidieux, 
ce qui interdit en pratique le traitement de gros volumes de programmes. 
De plus, il faut repayer le cofit du controle a chaque nouvelle version du 
prograname, de la plate-forme d'execution ou des criteres. Par ailleurs, 
cette approche suppose en pratique que le code som'ce du programme est 
disponible, ce qui est peu souvent le cas pour des raisons de confidentialite 
ou de propriete industrielle. Lorsque seul le code objet est disponible, 
I'analyse manuelle devient extramement longue et difficile, et le risque 
d'une erreur humaine est multipiie d'autant. 

• Le programme peut aussi etre controle automatiquement, avec I'aide d'un 
outil d'analyse. Plusieurs types d'outil existent aujourd'hui : 

- Certains outils verifient a I'aide d'une analyse statique que le code d'un 
programme respecte des regies generales de bonne formation et de bon 
typage, ce qui apporte certaines garanties de bon fonctionneraent, quelle 
que soit la plate-forme cible. C'est par exemple le cas des verificateurs de 
code octet (« bytecode verifiers ») associes aux environnements d'exdcution 
« Java », y compris « Java Card », De tels analyseurs de types peuVent 
fonctionner aussi bien sur le code source que sur le code objet. lis ne 
repondent toutefois pas a des criteres particuliers, concemant pai' exemple 
la secijrite ou I'interopdrabilite. - 

D'autres outils, surtout destines aux developpeurs, verifient a I'aide d'une 
analyse statique que le code d'un programme ne peut pas effectuer 
d'operations qui n'ontpas de sens, comme de dereferencer un pointeur nul 
ou acceder k un 616ment de tableau hers des limites. Ces outils apportent 
ainsi certaines gai-anties de bon fonctionnement, quelle que soit la plate- 
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forme cible. Mais comme poxir les analyseurs de type, ils ne repondent pas a 
des criteres particuliers. 

- Enfm, certains outils examinent le code du programme, source or objet, 
5 pour rechercher des occurrences d'appels de routines. lis permettent ainsi 

d'appliquer des criteres specifiqnes qui interdisent T usage de certaines 
routines (que ce soit pour des raisons de securite ou d'interoperabilite) : ils 
rejettent tout programme qui comportent des appels a ces routines. 
Cependant, de tels outils ne peuvent pas non plus verifier le genre de regie 
10 donne en exemple ci-dessus : il faut non seulement detecter que la methode 
« buildKey » est appelee mais aussi savoir si son premier argument est egal 
a « TYPE_DES » et son deuxieme argument inferieur a 128. 

Compte tenu des problemes precedemment evoques, Tinvention a plus 
15 particulierement pour but de permetti'e le developpement d'outils de controle 
qui peuvent d' adapter aux besoins de regies sp6cifiques tout en permettant la 
verification automatique de regies complexes, concemant notamment la valeur 
possible des arguments de certaines operations et renchaitiement de telles 
operations. 

20 

A cet effet, elle propose un precede pour la determination de caracteristiques 
operationnelles d'un programme mettant en oeuvre une procedure de 
verification comportant les etapes suivantes : 

25 - une premiere etape d' expression des caracteristiques operationnelles' du 
programme comme des fonctions portant sur des evenements pouvant se 
produire au cours des executions possibles du programme ; 

- une deuxieme etape d' extraction, par des analyses de programme, a la fois 
30 de la structure du programme, des chemins. d' execution possibles et des 

vaieurs manipulees en differents points du programme ; 
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- une troisieme etape de determination desdites caracteristiques en calculant 
les fonctions associees, grace aux informations extraites par lesdites 
analyses. 

Ce precede pourra prendre en compte les paramdtres suivants : 

- un ensemble de caracteristiques concemant les operations que le 
programme peut effectuer au cours de son execution, et/ou 

- un degr6 de precision eventuel avec lequel ces caracteristiques doivent Stre 
determinees, et/ou 

- un ensemble 6ventuel de contextes d' execution particuliers dans lesquels le 
programme sera toujours execute, et/ou 

- une description 6ventuelle de sp6cificites operatoires d'un ensemble de 
plates-formes sur lesquelles le programme sera execute. 

Avantageusement, les informations extraites au cours de la deuxidme 6tape du 
precede pourront 8tre representdes k I'aide d'une ou plusieurs des structures 
suivantes : graphe d'etat du programme, graphe d'heritage, graphe d'appel des 
routines du programme, graphe de flot de contrdle de chaque routine du 
programme, structure de boucles et de rattrapage d'exceptions, structure de 
blocs de base (« basic blocks »), abstraction de I'etat du programme en un 
point d' execution, etant entendu que : 

- ladite extraction d' informations ne porte pas sur des informations inutiles k 
la determination des caracteristiques operationnelles, tant du point de vue 
de la quantite d' informations extraites que de la precision de ces 
informations. 
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- les informations majeures parmi lesdites informations extraites sont 
calculees et stockees, tandis que les autres informations ne sont calculees 
que lorsque necessaire pour la determination desdites caract&istiques 
operationnelles. 

Par « information majeure », on entend les informations extraites aux nceuds 
d'une decomposition du code des routines en un graphe de blocs de base 
(« basic blocks »), les autres informations (dans le corps des blocs de base) 
etant recalculees par une analyse locale k partir des informations stockees en 
debut et en fin de bloc correspondant. 

II apparait clairement que ce procede peut 6tre mis en oeuvre pour realiser un 
systeme d'execution multi applications garantissant que les applications 
respectent des criteres de validite donnes. 

L'invention s'applique en outre au filtrage automatique d'un ensemble de 
programmes par rapport h un ensemble de criteres de validity donnas. Dans ce 
cas, les susdites caract6ristiques operationnelles representent des criteres de 
validite. L'etape de determination etablit alors soit que le progranmie est 
valide parce qu'il respecte chacun desdits criteres ou invalide parce qu'au 
moins Tun desdits criteres ne peut pas Stre respect6. 

Les trois 6tapes de la procedure de va-ifiication mises en oeuvre par le proc6d6 
selon Finvention seront decrites plus en detail ci-apres, a titre d'exemple non 
limitatif. 

Expression des criteres : 

Dans un premier temps, les criteres sont traduits en termes d'evenements 
defmis comme la realisation d'operations paiticulieres portant sur des valeurs 
particulieres en des points de programme particuliers. A titre d'exemple. 
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certaines desdites operations particulieres (qui, accompagnees de contraintes 
SUV les valeurs manipulees, les points execution, et les etats du prograiTime, 
fonnent des evenements) sont definies comme Tune des actions suivantes : 
appel a nne routine dorniee, acces a une variable donnee, lecture ou 6criture 
sur un port donne, calcul d'une expression arithmetique donnee, fin 
d'execution du progt'amme ou d'une routine (sur un retour normal ou une 
levee d' exception). 

Un evenement est par exemple Tappel a une routine avec un argument k 
rinterieur d'un certain intervalle (cf. exemple ci-dessus concernant Tappel a la 
methode « buildKey » avec un argument inferieur k 128), I'acces a un element 
de tableau a un certain indice, le fait que les arguments d'une addition sont tels 
que raddition pent deborder, Patteignabilite d'un point de programme sous 
une condition symbolique portant sur les valeurs manipulees par le 
programme, le fait que le programme ou une routine termine dans un etat 
particulier en levant une exception particuliere, etc. 

Un critere m6me s'exprime comme une fonction qui porte sur les occurrences 
ou sequences particulieres d'occurrences de tels evenements, au cours des 
diverses executions possibles du programme. On pent ainsi modeliser des 
criteres relativement complexes. 

Un cadre possible pour T expression formelle de tels criteres est la logique 
temporelle lineaire (LTL). Ce formalisme permet d'exprimer par exemple que 
des 6venements se produisent toujours, ou bien tot ou tard, ou bien qu'une 
condition reste vraie jusqu'a ce qu'im evenement se produise, etc. 

'Par exemple, «Java Card» foumit ime aide specifique pour realiser une 
transaction (mise a jour atomique de Tetat permanent du systeme). Pour cela, 
il faut appeler la methode « beginTransactionQ », effectuer des mises a jour, 
puis appeler la methode « commitTransactionQ ». On est alors garanti qu*en 
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cas de remise k jour (notamment interapestive) de la carte, soit aucune 
modification n'aura effectuee, soit toutes les modifications n'auront ete 
effectuees. Le critere de validite des transactions stipule notamment que la 
m6tliode « commitTransactionQ » ne doit etre appelee qu'apres I'appel de 
5 « beginTransactionO ». 

Les sequences d'evenements peuvent aussi faire intervenir les valeurs 
manipulees par le programme. Par exemple, si un critere stipule qu'on ne peut 
pas liberer une ressource sans 1' avoir auparavant allouee — sinon la liberation 

10 echouerait — , on peut defmir une regie explicite du type suivant : une routine 
donn6e (par exemple de liberation de ressource) ne peut 6tre appelee avec un 
certain ar^ment que si cet argument a ete la valeur de retour d'une autre 
routine donn6e (par exemple d' allocation de ressource) appelee 
precedemment. Un tel exemple dans 1' implementation «Java Card » de la 

15 specification « Open Platfonn v2.0. 1 ' » est donne par la meUiode de fenneture 
de canal securis6 (« closeSecureChannei »), qui doit ^tre appelee avec comme 
argument la valeur de retour de la methode d'ouverture de canal securise 
(« openSecureChannel »). Le programme suivant est invalide en ce sens : 
void process(APDU apdu) { 

20 

chanNum = openSecureChannel(apdu); 
closeSecureChannel(O) ; 

25 } 

En effet, pour que ce programme soit valide, il faudrait que la fermeture du 
canal securise s'effectue par « closeSecureChannel(chanNum) ». De fait, ce 
programme ne fonctionne que dans le cas ou la methode 
30 « openSecureChannel » retoume la valeur 0. 

On peut aussi par exemple vouloir s'assurer que des traitements specifiques 
doivent necessaireraent etre prevus pour un ensemble de circonstances 
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particulieres. Un critere associe peut par exemple s'exprimer par la regie 
suivante : pour toute valeur d'un argument dorniee d'une routine donnee (par 
exemple d'enregistrement de T application aux interruptions ou evenements 
' programmatiques designes par cet argument), il existe du code d'une autre 
5 routine donnee (par exemple de traitement des interruptions ou evenements 
programmatiques auxquels T application est abonnee) qui est uniquement 
atteignable lorsque cette autre routine est appelee avec en argument ladite 
valeur. 

10 La traduction des criteres en terme de regies explicites ainsi formul6es peut 
s'effectuer une fois pour- toute, tant que les criteres restent les m6mes. Sauf 
dans le cas particulier de criteres dependant d'une specification ou d'une 
implementation de programme donnee, la traduction est en effet independante 
des programmes, 

15 

Extraction d'informations par analyses de programme : 

Dans un deuxieme temps, pour un programme donne, des analyses statiques 
extraient des informations concernant la structure du programme, les chemins 
20 d'execution possibles du programme et les valeurs possibles, sous differentes 
conditions d'execution> des donnees manipulees en divers points des chemins 
d' execution. 

II existe un ensemble de techniques coxmues pour determiner des informations 
25 sur les chemins d' execution possible du programme. Ces techniques 
permettent de calculer notamment le graphe d'appel des routines du 
programme et, pour chaque routine, son graphe de flot de controle (dont les 
noeuds sont regroupes ou non dans des blocs de bases) et sa structure de 
boucles et de rattrapage d'exceptions. Ces diverses structures de donnees sont 
30 des expressions finies et regulieres qui peuvent representor en fait une infinite 
de chemins d' execution et qui forment im surensemble (pour des raisons 
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d"" approximation expliquees ci-dessous) de Pensemble de toiis les chemins 
d' execution possibles du programme. 

II existe egalement des techniques, notamment 1' interpretation abstraite, qui 
5 permettent d'obtenir des valeurs approchees (par exemple, des ensembles de 
valeurs possibles) des donnees manipulees par le programme en divers points 
d' execution du code. Ce type disinformation est ordinairement calcule afin de 
detecter des operations elementaires qui risquent d'echouer, comme la* 
dereference d'un pointeur nul ou I'acces a un element de tableau hors de ses 

10 limites. Mais T interpretation abstraite est plus generale. Elle pent notamment 
manipuler des valeurs symboliques et ^insi determiner les conditions abstraites 
associees aux divers chemins d' executions que le programme pent emprunter. 
Cela permet par exemple de savoir^ comme dans Texemple des traitements 
specifiques ci-dessus, si un point de programme est uniquement atteignable 

1 5 sous une condition particuliere, donnee ou calculee. 

D'autres elements d' architecture du progi*amme, comme le graphe d'heritage 
(exprimant la hierarchie de classes dans le cas des langages a objets), peuvent 
aussi etre determines. 

20 

Determination du respect des criteres : 

Dans un troisieme et dernier temps, les criteres sont evalues sur les 
informations extraites par les analyses, Autrement dit, les fonctions associees 

25 aux criteres sont evaluees en considex-ant, pour Tensemble des chemins 
d'execution possibles calcules, les occurrences ou sequences particulieres 
d'evenements constitues par la realisation d'operations particulieres en des 
points de programme particuliers et portant sur des valeurs particulieres. La 
nature effective des calculs depend de la formulation des criteres et des types 

30 d' informations extraites par les analyses. 
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De nombreux perfectioimements de rinvention peuvent etre construits sur la 
base de la procedure decrite ci-dessus. Des exemples de tels 
perfectioimements, qui sont combinables les uns avec les autres, seront d^crits 
individuellement ci-apres. 

5 

Parametrisation de la precision : 

On observera tout d'abord que^ dans le cas general^, les chemins d'execution et 
les valeurs manipulees par le programme correspondent a des propriet6s 
10 mathematiques dites indecidables : on ne peut pas les determiner avec 
exactitude mais on peut toutefois les approcher. En pratique, cela signifie 
qu'on ne peut connaitre les chemins et les valeurs manipulees qu'avec une 
precision limitee. 

15 Or il est souvent primordial que ces informations soient determinees avec une 
grande precision/ Dans le cas contraire, on peut signaler qu'un critere (par 
exemple qui impose qu'xme quantite soit positive) risque de ne pas 6tre 
respecte (par exemple parce qu'on a pu seulement determiner que cette 
quantite pouvait gtre comprise entre -10 et 30) alors qu'une meilleure 

20 precision d' analyse (par exemple qui determinerait que cette quantite ne peut 
en fait qu'etre comprise enti'e 5 et 20) aurait permis de conclure que le critere 
est toujours respecte. 

En Tabsence d'une precision suffisante, il faut soitxejeter Papplication «par 
25 securite» (au risque de rejeter une application inoffensive), soit contrdler 
manuellement les criteres sur lesquels Tanalyse automatique n'a pu conclure. 
En cas d' analyse manuelle, on peut beneficier des infonnations extraites par 
r analyse qui, bien que pas suffisamment precises, permettent souvent 
neanmoins de circonscrire le perimetre de la verification, 

30 
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Dans tous les cas, il est avantageux de permettre une parametrisation de la 
precision avec laquelle on effectue lesdites analyses. Ce parametrage peut 
concemer les domaines de valeurs abstraites. Par exemple, les valeurs entieres 
peuvent etre abstraites par des valeurs exactes (ou la valeur indeterminee) ou 
par des intervalles. De meme, les references peuvent etre abstraites par leur 
type; les tableaux, par une indication de leur longueur; les chaines de 
caractferes, par une indication du prefixe connu (eventuellement vide) de la 
chame, etc. Le parametrage peut aussi concemer les points de fusion de 
valeurs au cours de 1' interpretation abstraite : analyse sensible au point de 
progranmie ou non, analyse mono-procedurale ou inter-procedurale, analyse 
sensible au contexte ou non, etc. 

Execution du programme dans des contextes particuliers : 

Par ailleurs, quelle que soit la precision de 1' analyse, les valeurs approchees 
des donn6es manipulees sont des proprietes du programme qui sont vraies 
pour toutes les executions possibles du programme, c'est-a-dire quels que 
soient ses arguments d' entree. Or il est des cas on Ton sait que le programme 
ne sera utilise que d'une certaine maniere, dans certains contextes, c'est-a-dire 
avec des contraintes connues concemant ses arguments. 

En cette circonstance, on peut am61iorer la precision de 1' analyse en prenant 
en compte des hypotheses sur les valeurs de ces arguments. Dans le cas d'une 
analyse pas interpretation abstraite, au lieu de supposer tous les arguments 
indetermines, on peut notamment donner des valeurs abstraites particulieres 
aux parametres (y compris de configuration) et arguments du programme 
avant de lancer 1' analyse. 

Calculs reduits aux informations n^cessaires : 
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Outre la precision des informations calculees^ la quantite de ces informations 
est aussi un paxametre sur lequel on pent jouer. En particulier, 11 n'est pas 
necessaire qu'une analyse de programme determine toutes les valeurs 
manipulees en tons les points de programme. En effet, seules les informations 
5 qui interviennent dans les formules qui representent les criteres n'^ont a etre 
calculees et memorisees iors des analyses. 

Pour reduire encore davantage la quantite d' informations stockees, on pent 
aussi ne memoriser des infomiations qu'en certains points critiques et 

10 recalculer les informations manquantes seion les besoins de revaluation des 
criteres. Par exemple, on peut ne mem*oriser les informations qu'aux noeuds 
d'une decomposition du code des routines en un graphe de blocs de bases 
(« basic blocks ») ; lorsqu'une information est necessaire en un point de 
programme quelconque d'un bloc de base, elle peut aisement etre recalculee 

15 par une simple analyse locale a partir des infonnations stockees en debut et fin 
de bloc. 

Ces optimisations reduisent les ressources (espace memoire, temps de calcul) 
necessaires pour la mise en ixuvre de la procedure de verification. A 
20 ressources constantes, ces optimisations pennettent aussi une meilleure 
precision, et done une reduction ou disparition des eventuelles verifications 
manuelles additionnelles- 

Calculs d'informations et evaluation des criteres simultan(^s : 

25 

Dans le meme esprit de reduction des ressources consommeeSj certains 
criteres peuvent aussi etre evalues au vol, au cours des analyses de 
programmes. En combinant, au moins pour certains critdres, les deuxieme et 
ti'oisieme etapes de la procedure de verification, on evite un stockage massif 
30 d' informations, mSme temporaire : ^information est consommee des qu'elle 
est produite, et ensuite peut etre oubliee. 
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Verification de programmes interactifs : 

Par ailleurs, la procedure decrite ci-dessus pent etre appliquee a un programme 
5 interactifj c'est-a-dire a im prograimne qui depend d'un nombre indetermine 
de valeurs dynamiques extemes resultant de cette interaction. Un tel 
programme pent en effet etre vu comme un programme qui lit 
progressivement des suites de doraiees, eventuellement infmies (les contextes 
d' execution sont donnes ici par une description abstraite des suites de donnees 
10 possibles representant lesdites valeurs dynamiques), Ces suites de doimees 
peuvent Stre modelisees par des valeurs abstraites finies au m8me titre que les 
autres arguments du programme, pour les besoins des analyses statiques. 

Verification de programmes dans des cadres d' execution : 

15 

De plus, dans certains cas, une partie de la logique du programme pent dtre 
g6ree par un cadre d' execution (« framev/ork »), implemente sur les plates- 
formes. Par exemple, les applications « Java Card » s'inscrivent dans un tel 
cadre. Une application « Java Card » doit notanraient heriter de la classe 

20 «javacard.framework. Applet » et definir deux methodes : « install Q » et 
« processQ », L'execution du programme consiste en Tappel par la plate- 
forme de la m6thode « installQ » avec en argument un tableau d'octets, puis 
(en omettant pour simplifier la question de la selection) en un nombre 
indetermine d'appels de la m^thode « processQ » avec, a chaque appel, un 

25 nouveau tableau d' octets en argument. (On peut remarquer que les 
applications « Java Card » sont ainsi egalement des programmes interactifs au 
sens indique ci-dessus). 

Pour appliquer la procedure decrite ci-dessus a de tels programmes, il faut 
30 aussi prendre en compte le cadre d'execution, Dans Texemple de « Java 
Card », cela peut conduire a rendre explicite pour les analyses la boucle qui est 
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implicite dans le cadre d'ex6cution, qui effectue les appels de la methode 
« processQ ». 

Les analyses statistiques pourront prendre en compte la s6mantique de ce 
5 cadre d'execution (y compris les eventuelles boucles d'interaction implicites 
du programme). 

Graphe d'etats : 



15 



10 Pom- augmenter la precision des analyses, H est aussi parfois necessaire de 
«derouler» les boucles et appels r6cursifs du programme en fonction 
. d'informations concemant les valeurs manipulees par le programme a 
I'execution. On obtient ainsi non pas des informations globales qui sont vraies 
quel que soit le nombre d'iterations d'une boucle ou d'appels r6cursifs, mais 
des informations locales, pour chaque tour de boucle ou appel r6cursif Ce cas 
figure se produit notamment dans le cas de programmes interactifs qui • 
s'inserent dans des cadres d'execution. Par exemple, dans le cas d'une ^ 
application «Java Card», les appels successifs a la methode « processQ » - 
peuvent conduire k des r6sultats d'analyse differents en fonctions des etats du ^ 
20 programme calcules lors des appels precedents . 

L'analyse de I'application, apres deroulage de la boucle d'interaction implicite 
ainsi que abstraction et identification des etats du programme, foumit alors 
comme r^sultat un graphe d'etats sur lequel peuvent 8tre calcules les criteres. 
Les noeuds de ce graphe d'etats representent les etats de I'application ; les 
transitions de ce graphe sont etiquetees par ies differents classes d'arguments 
foumis a la methode « processQ ». 



25 



Sp^cificit^s operatoires des plates-formes d'execution : 
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Par ailleurs, comme indique en introduction, le bon fonctionnement d'un 
programme depend de la plate-forme d' execution, qui pent implementer ou 
non^ convenablement ou non, certaines fonctionnalites. 

5 Afin de pr6voir correctement ou plus finement le comportement d^'un 
programme sur une plate-forme ou un ensemble de plates-formes donne, les 
specificites operatoires de ces plates-formes (par exemple le comportement 

des librairies) peuvent etre foumies et exploitees au moment des analyses de 
programme. Bien sur^ revaluation des criteres en fonction d'infomiations 
10 extraites de telles analyses est alors specifique aux plates-formes cibles 
correspondantes. 

Dans le cas d'une analyse par interpretation abstraite, les specijBcites 
operatoires peuvent etre donnees par des fonctions abstraites qui definissent la 
15 semantique des operations particulieres de ces plates-formes. 

Generalisation aux caracteristiques operationnelles des programmes : 

II est important aussi de noter que la procedure decrite ci-dessus ne se limite 
20 pas a des criteres booleens et couvre de fait un spectre plus large que celui de 
la validation d' applications. Plus general ement, cette procedure permet en 
effet de determiner des caracteristiques op6rationnelles d'un programme. 

Par exemple, le procede selon Tinvention permet, grace a ses trois etapes, de 
25 determiner les ressources consommees par le programme lors de son 
execution, comme par exemple la quantite totale de memoire allouee. La 
reunion des informations d'acces aux ressources, collectees le long des divers 
chemins d' execution possibles, fournit en effet un encadrement des ressources 
consommees. 

30 
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Cette procedure permet aussi notamment de determiner les fonctionnalites de 
la plate-fonne d'ex6cution qui sont exploitees par le programme lors de son 
execution. On peut reunir pour cela les fonctionnalites utilisees qui sont 
recensees ie long de chacun des chemins d'execution possibles. 

5 

Validation de nouveaux critdres : 

On peut egalement observer que la procedure decrite ci-dessus analyse un 
unique programme donne par rapport a des criteres donnes, criteres 
10 eventuellement specifiques a une unique plate-forme ou classe de plates- 
formes d'execution donnee. 

Toutefois, il n'est pas forc6ment necessaire de re-analyser un programme 
quand se pose la question de son adequation a de nouveaux criteres ou a une ! 
15 nouvelle plate-forme d'execution. II suffit en effet de re-exploiter les ^ 
informations precedemment extraites, et par exemple stockees dans une base 
de donnees. 
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Validation et filtrage d'un ensemble de programmes : 



En reunissant les caracteristiques extraites d'un ensemble de programme, on 
obtient aussi une procedure de validation d'un groupe de programmes destines 
a resider ensemble sur une plate-forme donnde. Autrement dit, on peut 
composer des groupes de programmes qui forment un tout coherent par 
25 rapport a des critdres donnes. 

Cette fonctionnalite peut 6tre utilisee comme filtre sur un serveur 
d'applications. Connaissant les caractdristiques de la plate-fonne d'execution 
d'un utilisateur de ce service, les applications incompatibles avec cette plate- 
30 forme sont masqu6es. L'utilisateur n'a ainsi accds qu'aux applications qui sont 
compatibles avec sa plate-forme d'execution. II est ainsi garanti du bon 
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fonctionnement de toute application qu'il voudrait charger, II faut noter qu'il 
n'est pas necessaire de refaire les analyses de programme pour proposer une 
liste d'applications valides a un utilisateur : les resultats d' analyse sont 
rentilises ; seuls les calculs correspondant an test de compatibilite par rapport a 
5 la plate-forme d'execution sont a refaire, s'ils n'ont pas eux aussi deja ete 
calcules, 

De preference, Textraction d' informations par, analyse statique de programme 
n'est effectuee qu'une fois par programme et reutilisee a chaque fois que 
10 necessaire pour determiner si le programme respecte un ensemble de criteres 
de validite donne. 

Abstraction des informations extraites : 

15 En pratique, les resultats d'une analyse statique de programme peuvent etre 
assez volumineux et done difficile a stocker. Quand c'est le cas^, il pent etre 
avantageux d'abstraire ces resultats pour ne conserver que des informations 
simplifiees. 

20 On peut notamment se limiter a un profil d'execution, defini par exemple 
comme T ensemble des fonctionnalites exploitees par le programme et la 
quantite maximale de ressources consommees au cours d'une execution 
quelconque. Un tel profil, qui ne fait en particulier pas apparaitre la notion de 
chemins d^execution, requiert un espace memoire de stockage beaucoup plus 

25 faible, II est aisement compare a un ensemble de fonctionnalites connues 
comme disponibles sur la plate- forme pour les questions d'interoperabilite, un 
ensemble de fonctionnalites declai^ees utilisables selon des criteres de securite, 
et une borne concernant la consommation des ressources. 

30 Get usage du procede permet d'elaborer le « diagnostic » d'une application, 
pour une classe de criteres et de plates-formes d'execution particulieres. 



1er depot 



Validation embarqu^e : 

La detenxiination de caract^ristiques operationnelles peut s'effectuer, tout on 
5 partie, sur la m6me plate-forme qui execute le programme, Ce cas de figure est 
particulierement interessant dans le cas ou les caracteristiques operationnelles 
sont des regies de validite qui expriment le respect par un programme de 
criteres particuliers et ou la plate-forme d' execution est un systeme embarque, 
comme par exemple un telephone mobile ou une carte k puce. 

10 

Deux cas particuliers sont k noter. Dans le premier cas, k la fois T extraction 
des informations et revaluation des regies de validite sont effectuees sur la 
plate- forme d' execution du programme. Dans le second cas, I'extraction des 

informations par analyses de programme est effectuee en dehors de la plate- 
15 forme ; elle est ensuite transmise a la plate- forme, par exemple au moment du 
chargement du programme ; enfin, revaluation des regies de validite k Paide 
des informations transmises est effectuee sur cette meme plate-fomie. 

Comme precedemment mentionne, Tinvention concerne 6galement un systeme 
20 mettant en oeuvre le procede precedemment d6crit pour garantir que des 
appUcations proposees par un serveur a des clients respectent des criteres de 
validite associes aux plates-formes d'execution de ces applications. 

Ce systeme pourra avantageusement comprendre des moyens de filtrage 
25 confus de maniere a ce que, pour tout client desirant acceder aux applications 
pour une certaine plate-forme d' execution, les applications soient filtrees 
conformement a la procedure de verification precedemment decrite et que 
seules les applications qui respectent les criteres de validity pour ladite plate- 
forme soient presentees au cUent. 

30 



1erdep6t. 

-24- 



De m6me, I'invention conceme un systoe d'ex^cution multi applications 
garantissant que les applications respectent des criteres de validit6 donn6s, ce 
systeme faisant intervenir un serveur d'analyses d' applications, un searveur de 
validation d' applications et une plate-forme d' execution multi applications. 

Ce systeme fait en outre intervenir des moyens permettant d' assurer, avant le 
chargement ou I'ex^cution d'une application sur la plate-forme : 

- le respect par cette application desdits criteres conformement au proc6d6 
precedemment 'decrit, I'extraction d'information s'effectuant sur le serveur 
d'analyses d'application tandis que revaluation desdits criteres s'effectue 
sur le serveur de validation d' applications, et 

- dans le cas ot un des criteres ne pent pas Stre respect6, I'echec du 
chargement ou de 1' execution de 1' application, la modification de I'etat du 
systeme et remission d'un signal sonore ou visuel pour avertir de I'echec 
du chargement ou de 1' execution. 

Dans ce systeme, le serveur de validation d' applications pourra s'ex6cuter sur 
la plate-forme d'execution multi applications, le serveur d'analyses 
d' applications s'executant hors de la plate-forme. Eventuellement, le serveur 
d'analyses d' applications et le serveur de validation d'applications pourront 
s'ex6cuter sur la plate-forme d' execution multi applications. 
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Revendications 

1 . Proced6 pour la determination des caracteristiques operationnelles 
d'un programme^ 

5 caracterise en ce qu'il comprend une procedure de verification coniportant les 
etapes suivantes : 

- ime premiere etape d' expression des caracteristiques operationnelles du 
programme comme des fonctions portant sur des evenements pouvant se 

10 produire au cours des executions possibles du programme ; 

- une deuxidme etape d' estimation, par des analyses de programme, a la fois 
de la structure du programme, des chemins d' execution possibles et des 
vaieurs manipulees en differents points du programme ; 

15 

- une troisieme etape de determination desdites caracteristiques en calculant 
les fonctions associees, grace aux informations extraites par leBdites 
analyses. 

20 2. Procede selon la revendication 1, 

caracterise en ce les susdites cai^acteristiques operationnelles sont 
independantes du susdit programme. 

3. Procdde selon la revendication 1, 
25 caracterise en ce qu^il prend en compte : 

- un ensemble de caracteristiques concernant les operations que le 
programme peut effectuer au cours de sozi execution, eVou 

30 - un degre de precision eventuel avec lequel ces caracteristiques doivent eti-e 
determinees, et/ou 
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un 



ensemble eventuel de contextes d'ex6cution particuliers dans lesquels le 
programme sera toujours execute, et/ou 

- une description eventuelle de specificit6s operatoires d'un ensemble de 
plates-formes snr lesquelles le programme sera execute. 

4. Precede selon la revendication 3, 

caracterise en ce que la susdite premiere etape comprend I'expression desdites 
caracteristiques operationnelles comme des fonctions portant sur les 
occurrences ou sequences particulieres d' occurrences, au cours des diverses 
executions possibles du programme, d'ev6nements defmis comme la 
r6alisation d'operations particulieres, portant sur des valeurs particulieres, en 
des points de programme particuliers, dans des 6tats particuliers du 
programme. 

5. Precede selon la revendication 3, 

caracterise en ce que la susdite seconde etape comprend I'extraction, a I'aide 
d' analyses' statiques de programme et en tenant compte dudit degre de 
precision eventuel avec lequel les caracteristiques doivent etre determinees et 
desdites specificites operatoires eventuelles de plates-formes d' executions, 
d'informations concemant la structure du programme, les chemins d' execution 
possibles du programme et les valeurs possibles, en divers points des chemins 
d'execution et sous differentes conditions d'execution, des etats et donnees 
manipuiees par le programme. 

6. Procede I'une des revendications 4 et 5, 

caracterise en ce que la susdite troisieme etape comprend la determination, a 
I'aide desdites informations extraites, desdites caracteristiques operationnelles 
par le calcul desdites fonctions sur les occurrences ou sequences particulieres 
d' occurrences d'operations particulieres, portant sur des valeurs particulieres, 
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en des points de programme particuliers, dans des etats particuliers du 
programme, pour Fensemble des chemins d'execution determine par les 
analyses. 

5 7. Procede selon la revendication 3, 

caracterise en ce que^ dans le cas ou le programme est interactif et pent 
dependre d'un nombre indetermine de valeurs dynamiques resultant de cette 
interaction, les contextes d'execution sont donnes par une description abstraite 
des suites de donnees possibles representant lesdites valeurs dynamiques. 

10 

8. Procede selon la revendication 1 , 

caracteris6 en ce que, dans le cas oil le programme s'insere dans un cadre 
d' execution (« framework »), les analyses statiques prennent aussi en compte 
la semantique de ce cadre d' execution, y compris les eventuelles Soucles 
15 d' interaction implicites du programme, 

9. Proc6d6 selon la revendication 4, 

caracterise en ce que certaines desdites operations particulidres " (qui, 
accompagnees de contraiates sur les valeurs manipulees, les jDoints 
20 d' execution, et les etats du programme, forment des evenements) sont definies 
comme Tune des actions suivantes : appel a une routine donnee, acces a une 
variable donnee, lecture ou ecriture sur un port donne, calcul d'une expression 
arithmetique donnee, fm d'execution du programme ou d'une routine (sur un 
retour normal ou une levee d' exception). 

25 

10. Procede selon la revendication 5, 

caracterise en ce que certaines desdites analyses statiques sont constituees par 
des inteipretations abstraites du programme, sur des domaines abstraits qui 
peuvent representor notamment des ensembles de valeurs possibles et des 
30 expressions symboliques. 



ler depot ■ 

-28- 

IL Precede selon la revendication 5, 
caracterise en ce que lesdites informations extraites sont representees a I'aide 
d'nne ou plusieurs des structures suivantes : graphe d'etat du programme, 
graphe d'heritage, graphe d'appel des routines du programme, graphe de flot 
5 de controle de chaque routine du programme, structure de boucles et de 
rattrapage d' exceptions, structure de blocs de base (« basic blocks »), 
abstraction de Fetat du programme en un point d' execution. 

12, Precede selon la revendication 5, 
10 caracterise en ce que ladite extraction d' informations ne porte pas sur des 
informations inutiles a la determination des caract6ristiques operationnelles, 
tant du point de vue de la quantite d'informations extraites que de la precision 
de ces informations. 

15 13, Precede selon la revendication 5, 

caracterise en ce que seules les informations majeures parmi lesdites 
informations extraites sont calculees et stockees et en ce que les autres 
informations ne sont calculees que lorsque necessaire pour la determination 
desdites caracteristiques operationnelles, 

20 

14. Precede selon la revendication 13, 
caracterise en ce que les informations majeures sont les informations extraites 
aux noeuds d'une decomposition du code des routines en un graphe de blocs de 
bases (« basic blocks ») et en ce que les autres informations (dans le corps des 
25 blocs de base) sont recalculees par une analyse locale k partir des informations 
stockees en debut et fin du bloc con*espondant. 



15, Procede selon la revendication 1 , 
caracterise en ce que lesdites caracteristiques operationnelles representent des 
30 criteres de validite et en ce que ladite determination etablit que le programme 
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est valide (parce qu'il respecte chacun desdits criteres) ou invalide (parce 
qu^au moins un desdits criteres peut ne pas €tre respecte). 

1 6. Precede selon la revendication 15, 

5 caract6rise en ce que iesdits criteres de validite expriment des regies de 
secxirite ou d'interoperabilite. 

17, Precede selon la revendication 1, 

caracterise en ce que lesdites caracteristiques operationnelles caracterisent les 
10 ressources qui sent consommees et les fonctiofinalites qui sent exploitees par 
le programme lors de son execution et en ce que ladite determination foumit 
un profil d' execution du programme. 



18. Precede selon Tune des revendications 5 et 6, 

15 caracterise en ce que le calcul de certaines desdites fonctions associees aux 
caracteristiques operationnelles est effectue au cours desdites analyses 
statiques de programme, des que certaines desdites informations sont ektraites. 

19. Application du precede selon la revendication 15 au filtrage 
20 automatique d'un ensemble de programmes par rapport a un ensemble de 

criteres de validite donne, 

caracterise en ce que 1' extraction d'inforaiations par analyse statique de 
prograimne n'est effectuee qu'une fois par programme et reutilisee a chaque 
fois que necessaire pour determiner si le programme respecte ledit ensemble 
25 de criteres de validity. 



20. Systeme de distribution d'applications garantissant que les 
applications respectent des criteres de validite associes aux plates-formes 
d' execution de ces applications, 
30 caracterise en ce qu'il comprend des moyens de filtrage conpus de maniere a 
ce que, pour tout client desirant acceder aux applications pour une certaine 
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plate-forme execution, les applications soient filtrees conformement k une 
procedure de verification comportant les etapes suivantes : 

- une premiere etape d' expression des caracteristiques operationnelles des 
5 programmes comme des fonctions portant sur des evenements pouvant se 

produire au cours des executions possibles des programmes ; 

- une deuxieme etape d' estimation, par des analyses des programmes, a la 
fois de la structm^e des programmes, des chemins d' execution possibles et 

10 des valeurs manipulees en differents points des programmes ; 

- une troisieme 6tape de determination desdites caracteristiques en calculant 
les fonctions associees, gr^ce aux informations extraites par lesdites 
analyses ; 

15 seules les applications qui respectent les criteres de validite pour ladite plate- 
forme etant presentees au client 

2L Systeme d'execution multi applications garantissant que les 
applications respectent des criteres de validite donnes, 
20 caracterise en ce qu'il comprend : 

- un serveur d'analyses d' applications, un serveur de validation 
d' applications et une plate-forme d'execution multi applications, et 

- des moyens permettant d'' assurer avant le chargement ou P execution d'une 
application sur la plate-forme : 

25 o le respect par cette application desdits criteres conformement au 

precede selon I'une des revendications 1 a 17, Pextraction 
d' informations s'effectuant sur le serveur d' analyses d' applications et 
revaluation desdits criteres s'effectuant sur le serveur de validation 
d' applications, et 

30 o dans le cas o*d un des criteres pent ne pas etre respecte, Techec du 

chargement ou de Texecution de Fapplication, la modification de 
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Tetat du systeme et remission d'un signal sonore ou visual pour 
avertir de Pechec du chargement ou de T execution. 

22. Systeme selon la revendication 21, 
5 caracterise en ce que le serveur de validation d* applications s'execute sur la 
plate-forme d'execution multi applications, le serveur d'analyses 
d' applications s'executant hors de la plate- forme. 

23, Systeme selon la revendication 21, 
10 caracterise en ce que le serveur d' analyses d' applications et le serveur de 
validation d' applications s'ex^cutent sur la plate-forme d'execution multi 
applications. 
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